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The NASA Integrated Network for Space Communications and Navigation (SCaN) has 
been in the definition phase since 2010. It is intended to integrate NASA’s three existing 
network elements, i.e., the Space Network, Near Earth Network, and Deep Space Network, 
into a single network. In addition to the technical merits, the primary purpose of the 
Integrated Network is to achieve a level of operating cost efficiency significantly higher than 
it is today. Salient features of the Integrated Network include (a) a central system element 
that performs service management functions and user mission interfaces for service 
requests; (b) a set of common service execution equipment deployed at the all stations that 
provides return, forward, and radiometric data processing and delivery capabilities; (c) the 
network monitor and control operations for the entire integrated network are conducted 
remotely and centrally at a prime-shift site and rotating among three sites globally (a follow- 
the-sun approach); (d) the common network monitor and control software deployed at all 
three network elements that supports the follow-the-sun operations. 


I. Introduction 

THE NASA Integrated Space Communications Network is intended to unify NASA’s three existing network 
elements, i.e., the Space Network, Near Earth Network, and Deep Space Network, into a single network. This paper 
describes the architecture of the integrated network concluded so far by the NASA-wide study. 1,2 It focuses on the 
integration of the diverse, heterogeneous communications assets and their operations, but does not cover the 
technology advancement aspect of space communications, e.g., optical communications, at the network. Figure 1 
illustrates the “should-be” architecture to be realized around the 2018 era. 

In this context, being “integrated” (adj.) means “making the elements of a system function coherently”. Clearly, 
the “system” here is the NASA integrated network and the “elements” are those equivalents of present Space 
Network (SN), Near Earth Network (NEN), and Deep Space Network (DSN). To avoid any confusion by the names 
of these networks, the elements or network elements of the system, i.e., the integrated network, are now changed to 
Earth Based Relay Element (EBRE), Near Earth Element (NEE), and Deep Space Element (DSE). The architecture 
options considered for this study include three approaches: as set- specific (retaining the current unique equipment of 
all three network elements), common (migrating to a single design that is deployed to the three network elements 
with some network element- specific adaptation), and centralized (migrating to a single design that is implemented 
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once to unified operation of the combined networks). The following matrix shows five possibilities, i.e., 
combinations of various implementation, deployment, and operations approaches, in selecting architecture options: 



Centrally deployed, 
centrally operated 

Multiply deployed, 
multiply operated 

Centrally deployed, 
multiply operated 

Multiply deployed, 
centrally operated 

Singly implemented 

X 

X 

X 

X 

Commonly, multiply 
implemented 

N/A 

X 

N/A 

N/A 


Since all three individual network elements can functionally be decomposed into three top-level functions: 
service execution, service management, and network control, we can address the integrated network in terms of 
integrating each of the three functions across the three network elements. As such, architecture options are identified 
for the integrated service execution (ISE), integrated service management (ISM), and integrated network control 
(INC) functions, respectively. Furthermore, for purpose of allocating functional capabilities to physical system 
entities, we have identified three types of physical system entities, i.e., the ground station site (GSS), the Network 
Operations Node (NON), and the Integrated Network Operations Center (INOC), for the integrated network. The 
integrated network architecture in terms of the three functions is described in Section IV of this paper. 
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Figure 1. The NASA Integrated Network Architecture around 2018 era - A Notional Illustration 


II. Key Characteristics of NASA’s Present Space Communications Network 

Key characteristics of the present space communications network(s) can be summarized are as follows: 

1) Diverse, heterogeneous communications assets: NASA currently operates complex space and ground 
infrastructure that supports all mission domains. The SN consists of a constellation of geosynchronous 
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relays to support missions in equatorial to highly inclined orbits from launch to Low Earth Orbit (LEO). 
The NEN consists of a set of NASA-owned and commercial ground stations for missions operating in 
orbital and suborbital locations, including LEO, GEO, and highly elliptical orbits and at lunar distances. 
The DSN consists of a set of large-aperture ground stations providing coverage of satellites from above- 
GEO distance to the edge of our solar system. The present network is very capable, but is also complex 
because of the heterogeneous nature of the component network assets and the lack of consistent service 
offerings, interfaces, and interoperability. 

2) No explicit, formal integrated network architecture: The NASA space communications infrastructure 
evolved into three distinct, unrelated component networks that provide domain- specific communications 
services. Until now, there has been no explicit network architecture documented using a formal 
methodology, and agreed by the Agency, to provide guidance to the evolution of an integrated space 
communications infrastructure. 

3) Independently evolved and operated networks: The present NASA space communication network 
elements have been independently evolving for as long as four decades on their own respective paths to 
provide TT&C services to flight missions. Infusion of new technologies and capabilities into each network 
has followed a road map at the individual network level. Each network is a distinct service-providing 
system largely functioning as a self-contained element. This approach offers certain strengths in that it 
allows each network to focus on the operational capabilities needed by its primary mission customer base 
using the most cost-effective and lowest risk approach possible. However, the present architecture does not 
include an orchestrated evolutionary path encompassing all networks. 

4) Mission requirements-driven network architecture: The evolution of the various networks has largely 
been driven by mission requirements. The growth in network capabilities very often depends on the needs 
of the few NASA flagship missions that have sufficient funding flexibility to advocate for more advanced 
performance and functionality. This factor contributes to the networks different services and to a slow, 
inefficient process for infusing new communications technology into the operational network assets. 

5) Diversely distinct service paradigms among the networks: While all network elements provide TT&C 
functionality, the types and levels of services offered by the SN, NEN, and DSN are very different. At the 
overall NASA service architecture level, there are few common, standard services defined for all three 
networks, and there is no uniform approach to establish standard service interfaces between the networks 
and customer missions. This network element- specific service provision approach has a number of 
deficiencies, particularly for mission users who need services from more than one network, and it impacts 
users during development, testing, and operations phases. Moreover, each network element employs its 
own tools and processes for service management. As a result, they offer user missions different degrees of 
controllability and visibility into network assets. The network- specific service management approach has 
served customers fairly well for a long time; but, as NASA moves into the next decade of space 
exploration, the Agency must adopt a more efficient, cost-effective approach to managing space 
communication services. A more integrated approach to managing services is urgently needed. 

6) Varying degree of interoperability within NASA and with networks of non-NASA space agencies: 
When providing support to missions requiring services of more than one NASA network element or the 
networks of non-NASA space agencies, the three NASA network elements take different approaches to 
accomplish interoperability. In some cases, the approach taken by a network is ad hoc, varies from mission 
to mission, and depends on the particular assets involved in the cross support. 

7) Tool-assisted, operator-tended service providing systems: A common trait shared by the three NASA 
network elements is that they all rely heavily on human-operated tools for conducting day-to-day service 
provision activities. These activities include network scheduling, configuration set-up, monitoring and 
controlling the assets during the pass, and anomaly detection and recovery. The network elements differ, 
however, in the degree of automation applied. None of them has reached the state of unattended operations 
for nominal mission event support. 

8) Network-specific service pricing, cost attribution and accounting: Primarily due to the separate 
management of the network elements and their heterogeneous assets, NASA established different policies 
governing the pricing, cost attribution, and accounting of the services provided by the three networks. 
Service pricing algorithms, e.g., aperture fee calculations are network-dependent. Rules governing 
attribution of cost to user missions vs. the network elements are also different. 
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III. Key Characteristics of the NASA Integrated Space Communications Network 

The NASA integrated network that encompasses the three existing heterogeneous networks (hereafter labeled as 
“network elements”) must exhibit two important behaviors: (a) the integrated network as a whole or in part through 
each network element “behaves” as a single service providing system to user missions; (b) within the integrated 
network its hardware/software components and operational processes across the three network elements share a high 
degree of commonality and coherence. As shown in Figure 1, to the user missions the integrated network possesses 
the following key characteristics: 

• Provision of internationally interoperable, standard services to user missions by all network elements 

• Provision of standard service interfaces between all network assets and the ground systems of user missions 

• Provision of standard interfaces between all network assets and the flight systems of user missions over the 
space link. 

• Provision of standard service management capabilities for user missions to subscribe and request the space 
communications and tracking services. 


Key attributes including those associated with commonality and coherence internal to the integrated network are 
itemized in the following table: 


Function 

Key Attributes 

Service Management 

Common (but distributed) or physically centralized service management (to be decided). 

A Service Portal functions as the primary access point for user missions to interface with 
the NASA Integrated Network for service management capabilities. 


Central scheduling user interface capabilities for user missions to schedule services 
provided by all or any of the 3 network elements. 

Scheduling engine: common or network element- specific (to be decided). 

Network Control 

Fully integrated network control across all 3 network elements. 

Common network control software deployed at all 3 network elements. 

Integrated network control operations: Operational activities for network control are 
conducted globally at three Network Operations Nodes (NONs) where each of the three 
NONs monitors and controls the entire integrated network (EBRE, NEE and DSE) during a 
single prime- shift. A follow-the-sun, remote operations for network monitor & control. 

Common network control software derived from EBRE elements with network element- 
specific specialization and adaptation. 

Common, standard interfaces with MOCs, service management elements, service execution 
elements, and network control operators. 

A Service Portal functions as the virtually centralized interface point, for network monitor 
and control with user missions. 

Service Execution 

Standard services and service interfaces provided at all 3 network elements. 

Common (but distributed) service execution capabilities for all 3 network elements. High- 
degree of commonality in service execution equipment at all ground station sites (GSS) for 
all network elements. 

Common service execution capabilities based on EBRE developed capabilities (hardware 
& software) with network asset-specific adaptation. 

A Service Portal functions as the virtually centralized data delivery point, i.e., the “service 
dispatcher”, to user missions. 


IV. Integrated Space Communications Network - System Design 

This section addresses the integrated network architecture in terms of the integrated service execution (ISE), 
integrated service management (ISM), and integrated network control (INC) functions. 

A. Integrated Service Execution (ISE) 

The Service Execution function includes four types of services: the forward, return, and radiometric data 
processing and delivery services, plus position and timing service. For integrating these service execution functions 
across all three network elements, allocation of data processing and delivery capabilities at different levels, i.e., RF, 
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bit stream, frame, packet, and file, to the various physical system elements, i.e., ground stations sites (GSSs) locally 
vs. the integrated network operations center (INOC) centrally. The following table describes the options assessed: 


Option 

Description 

ISE-1 

Both processing 1 and data delivery/ transfer at Ground Station Sites 2 

ISE-2 

Processing 1 at ground station sites 2 ; data delivery/transfer at the Integrated Network Operations 
Center (INOC) 3 

ISE-3 

Both processing 1 and data delivery/ transfer at the INOC 3 

ISE-4 

Both processing 4 and data delivery/ transfer at the INOC 3 

Notes: All options are predicated upon the same degree of commonality in service capabilities among all mission 

domains, e.g., LEO, HEO, and deep space. 

1 Processing associated with TT&C services is at the levels above bit stream level. That means for return link 
service, regardless of which option (ISE-1 - ISE-3), at least the bit stream will be generated at the Ground 
Station Sites (GSS), and for command processing the GSS will always receive at least encoded bit stream. 

2 A GSS has one or more ground antennas with associated TT&C processing equipment with shared 
infrastructure, e.g. power, HVAC, frequency and timing, ground communications, and buildings. 

3 The INOC is a physical system element that performs the operations associated with the service management 
and network control functions for all the communications assets and elements. 

4 Processing associated with TT&C services is at the levels including and above bit stream level. 


After evaluating all options against a set of figures of merit (FOMs) and taking into account the risks, and cost 
estimates, the ISE-1, i.e., both data processing 1 and delivery at the individual ground station sites, is selected as the 
best- value alternative. 


Figure 2 depicts the integrated service execution architecture. Each of the network elements continues to provide its 
domain specific processing, and each ground station site does all of the forward and return data processing. 
Common data delivery services and interfaces are provided (as shown in the same color codes for network 
elements). Figure 3 shows the physical topology of the same architecture. 
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Figure 2. Integrated Network Architecture - Integrated Service Execution Function 

The integrated service execution architecture has the following key attributes: 
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• Standard services and service interfaces provided at all 3 network elements. 

• Common (but distributed) service execution capabilities for all 3 network elements. High-degree of 
commonality in service execution equipment at all ground station sites (GSS) for all network elements. 

• Common service execution capabilities based on EBRE developed capabilities (hardware & software) with 
network asset-specific adaptation. 

In addition, the architecture is adjusted to incorporate an important feature of the physically centralized options. 
A system element, the Service Portal is added to function as the virtually centralized data delivery point, i.e., the 
“service dispatcher”, to user missions. 
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Figure 3. Physical Topology of Integrated Network Architecture for Service Execution Function 


B. Integrated Service Management 

Service Management consists of three functions: service planning, service request scheduling, and service 
accountability and reporting. These functions are typically performed in a sequential manner with only small 
amounts of overlap. The major features of each function are described below. 

• Service Planning includes: 

• Perform radio frequency (RF) link analyses and assess impacts 

• Negotiate service agreements 

• Plan and allocate resources based on tracking requirements; perform coverage analysis 

• Perform loading analyses and assess impacts 

• Service Request Scheduling includes: 

• Negotiate contention resolution via peer-to-peer and/or priority based rule sets 

• Develop top-level service schedules 

• Service Accountability and Reporting includes: 
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• Assemble, filter, and mine the relevant source data 

• Assess service quality per service instance, missions, systems, networks and periodicity 

• Generate service accountability reports for the integrated network 

The future integrated network will provide mission users with a set of standard service management functions, 
primarily implemented using CCSDS service management standards. Interoperability between NASA network 
elements and assets operated by international partner agencies and commercial suppliers will be maximized. 

The network will also maximize commonality in service management among the network elements. The network 
will dispatch mission user requests to individual network elements and coordinate among the network elements, thus 
reducing user burden, improving integration, and enabling an integrated service commitment process. A contextual 
view of the service management functions, showing relationships and high-level data flows is shown in Fig 
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Figure 4. Integrated Network Architecture - Integrated Service Management Function 

For the integrated service management architecture, two options were assessed: (1) The physically centralized 
service management performed at a single Integrated Network Operations Center (INOC); (2) The common (but 
distributed) service management capabilities performed at the Network Operations Node (NON) of each network 
element. The present network element- specific service management will cease to exist. Figure 5 shows the 
reference design for the centralized ISM architecture. The key characteristics of the centralized ISM option are: 

1) A single INOC is implemented to perform the centralized service management functions for all the 
network assets of the IN. 

2) Coordination is performed within the INOC for support of users needing service from more than one asset 
class. 

3) Centralized service management will need to incorporate geographic redundancy for COOP, thus adding 
to the architecture option cost. 

4) Interfaces to asset specific network control will require network element specific gateway interfaces. 

Figure 6 shows the reference design for the common, distributed ISM architecture. The key characteristics of the 

common ISM option are: 

1) Common service management functions are implemented with standard service interfaces and behavior. 
There may be more than one implementation of these common service management functions. 

2) The set of service management capabilities are multiply deployed and operated, i.e., one for each NON- 
associated with a site or group of sites. 

3) Coordination is required among service management instances for support of users needing service from 
more than one NON. 

4) Distributed service management and network control will provide geographic redundancy for COOP. 
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Figure 6. Common Service Management - Reference Design 


Regardless of which of the two options is of better value, it is determined that, as the initial step, a Service Portal 
serving as the primary access point for user missions to interface with the NASA Integrated Network for service 
management and network control capabilities must be built. The Service Portal, from the view of user missions, is a 
web-based system facilitating the following service management activities: 
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• Access to the integrated network services catalog, services catalog for each network element, and user’s 
guide for each network element. 

• Access to the MOU, MO A, service level agreements, IRDs, and ICDs. 

• Interfaces with the Integrated Network for “service requests” in accordance with the CCSDS Service 
Management standard. 

• Interfaces with the Integrated Network for submitting spacecraft trajectory files in accordance with the 
CCSDS Service Management standard. 

• Interfaces with the Integrated Network for submitting spacecraft link configuration files in accordance with 
the CCSDS Service Management standard. 

• Access to the all the network schedule products. 

• Interfaces with the Integrated Network for viewing and receiving service accountability report at the end of 
each pass (i.e., for pass summary) and periodically (i.e., for daily, weekly, monthly, yearly, and mission-to- 
date reports). 

• Access to the RF link analysis tool(s) for performing the link design. 

• Access to the results of coverage analysis performed by the integrated network. 

• Access to the results of loading analysis performed by the integrated network. 

• Access to the scheduling tool(s) for entering and editing scheduling input (and service request) parameters. 

C. Integrated Network Control 

The Network Control includes primarily (1) the network asset configuration and control and (2) network asset 
monitoring functions. The integrated network control architecture is addressed from two different aspects: the 
network control software and network control operations. 

For assessing the integrated network control software (NCS) architecture, four options, as shown in the 
following table, were selected as the basis for the analysis of alternatives (AoA). Differentiating by the degree of the 
integrated nature and commonality, they range from the common network control framework to common interface 
software to gateway approaches. 


Software Alternatives 

Description 

Option 1 
(NCS-1) 

Common network 
control framework 

Common software framework for the entire network control functionalities 
across all network elements, i.e., EBRE, NEE, and DSE. Such a software 
framework includes common code providing generic network control 
functionality, but can be selectively adapted or specialized by network 
elements, thus accommodating network as set- specific functionality. 

Option 2 
(NCS-2) 

Common network 
control interface 

Common software components (within the network control function) that 
provide the interfaces with human operators, service management, and user 
mission elements. 

Option 3 
(NCS-3) 

Central gateway 

A singly implemented and centrally deployed gateway that functions as the 
single interface point (for the network control function) with the service 
management and user mission elements. The gateway performs necessary 
protocol conversions for the dissimilar and network as set- specific network 
control interfaces at the various network elements, i.e., EBRE, NEE, and 
DSE. 

Option 4 
(NCS-4) 

Network element 
gateway 

Multiply deployed gateways that function as the interface points (for the 
network control function) with the service management and user mission 
elements through common interface protocols. The gateway at each network 
element, i.e., EBRE, NEE, and DSE, performs necessary protocol 
conversions for the dissimilar and network asset-specific network control 
interfaces in each element. 


Figure 7 depicts the system context for each integrated network control software architecture alternative. 
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After evaluating all the options against a set of figures of merit (FOMs) and taking into account the risks, and 
cost estimates, the NCS-1 “Common Network Control Framework” option is selected. Key attributes of this option 
are as follows: 

1) A common software framework, derived from the EBRE software, is the core for the network control 
software at all three network elements, EBRE, NEE, and DSE. 

2) The common software framework will provide common, standard interfaces to: 

• Mission Operations Centers (MOCs) of user missions 

• Service Management elements resident at INOC (if Centralized Service Management is selected) or at 
NON and Service Portal (if Common Service Management is selected). 

• Service Execution elements 


NCS-1 


• Network control operators 

3) Specializations and adaptations of the common software framework for network element- specific network 
control capabilities will be primarily only through configuration files and scripts 

4) The common software framework will be singly developed and sustained, but multiply deployed. The 
scripts and configuration files will be created and maintained locally at each network element. 
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Figure 7. Integrated Network Control Software Architecture - System Context Per Options 


For assessing the integrated network control operations (NCO) in terms of processes and operations team 
structure and deployment, three options, as shown in the following table, were selected as the basis for AoA. 
Differentiating by the degree of the integrated nature and commonality, they range from a fully integrated network 
control operations approach to one featuring operations cross support by demands. Moreover, as an inherent part of 
the NCO AoA, the back-up approaches to achieving continuity of operations (COOP) in events of disaster are 
factored into the overall trades. Three options, COO-1, -2, and -3, were identified. They are discussed in a separate 
paper presented at SpaceOps’2012. 


10 

American Institute of Aeronautics and Astronautics 


Operations Alternatives 

Description 

Option 1 
(NCO-1) 

Fully integrated 
network control 
operations 

The operational activities for network control are conducted globally at three 
Network Operations Nodes (NONs) where each of the three NONs monitors 
and controls the entire integrated network (EBRE, NEE and DSE) during a 
single prime- shift. At each NON, operators for all network elements are 
physically co-located. 

Option 2 
(NCO-2) 

Partially integrated 
network control 
operations 

The operational activities for network control for each network element 
(EBRE, NEE, or DSE) are conducted at each Network Operations Node 
(NON). Cross-support among these NONs occurs for critical events, asset 
contention period (ACP), COOP, and other events demanding additional 
operational workforce for a network element. 

Option 3 
(NCO-3) 

Asset-specific 
network control 
operations 

The operational activities for network control for each network element 
(EBRE, NEE, or DSE) are conducted at each Network Operations Node 
(NON). No cross-support among these NONs takes place except for COOP 
purpose. 


Figure 8 depicts the system context for each integrated network control operations alternative. 
NCO-1 Fully integrated network control operations 



NCO-2 


Partially integrated network control operations 



Network 
Control Team 


Network Control 
Operational Process 


Network 
Control Team 


Network Control 
Operational Process 


— Central 
Service 
Man. 


Service Execution 


Network 
Control Team 


Network Control 


Operational Process 


MOC 


NCQ-3 Asset- specific network control operations 



2 

Figure 8. Integrated Network Control Operations Architecture - System Context Per Options 

In NCO-1 option, termed “Fully Integrated Network Control Operations”, the operational activities for network 
control are conducted globally at three Network Operations Nodes (NONs) where each of the three NONs monitors 
and controls the entire integrated network (EBRE, NEE and DSE) during a single prime-shift. Key attributes of 
NCO-1 are as follows: 
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1) A single Network Operations Node (NON) is responsible for network monitoring and control functions at 
any given time. 

2) The network control operations for the entire network, regardless of which network elements (EBRE, 
NEE, or DSE), are conducted at the prime-shift NON for a given shift (8 hours nominally). A follow-the- 
sun approach. 

3) At each NON, operators for all network elements are physically co-located. 

4) Features a common, standard operational process for network control across all network elements (EBRE, 
NEE, and DSE). 

5) Features a single integrated operational team, although its members are distributed physically at the 
various NONs, that conducts the network monitor and control activities. 

6) A firewall may be established for the special-class mission support to insulate it from other missions 
support. Only the NON at the EBRE conducts the special-class missions support. In other words, the 
folio w-the- sun rotation approach does not apply to special-class missions support. 

7) This option can be best accommodated by the Common Network Control Framework option for the 
software. 

8) Implies that all NONs must be equipped with network control software for all network elements. 

9) Implies that the integrated operational team must be trained extensively for monitoring and controlling all 
network elements. 

10) Implies that a high-degree of cross support among the NONs can be achieved when needed. 

11) Implies that the optimization on operations efficiency can be further assessed by taking into account the 
operational and maintenance personnel at each NON or GSS locally, as well as across the NONs. 

With the goal of achieving the fully integrated state for network control, via the NCS-l/NCO-1 solution, an 
evolution path should be taken: 

1) Proceed with NCS-1 prototype to evaluate functionality and viability of the common network control 
framework. 

2) Proceed with NCO-2, the partially integrated network control operations, using the NCS-1 prototypes to 
assess viability of integrated operations according to NCO-2 or NCO-1. 

3) If NCS-1 is deemed too hard to achieve due to cost and/or other circumstances, fallback to NCS-3, asset 
specific network control systems, retain common ISE, service management, & user missions interfaces. 

4) If NCO-2 (or NCO-1) evaluations fail fallback to NCO-3 resulting in NCS-3/NCO-3 solution. 

5) If NCO-2 (or NCO-1) evaluations prove their merits, move forward to the fully integrated state with the 
NCS-1 deployment and NCO-1 operations. 

Moreover, it is determined that, as the initial step, a Service Portal serving as the primary access point for user 
missions to interface with the NASA Integrated Network for service management and network control capabilities 
must be built. The Service Portal, from the view of user missions, is a web-based system facilitating the following 
network control activities: 

• Interfaces with the Integrated Network for viewing and receiving service execution status, alarm/alert, and 
monitor data during the pass and post-pass in compliance with the CCSDS CSTS monitor data standard. 

• Interfaces with the Integrated Network for generating and submitting control directives for the setup of 
user mission-controllable configuration parameters during the pass and pre-pass in compliance with the 
CCSDS CSTS service control standard. 

• Access to the SLE configuration parameters, i.e., those for establishing SLE “service binding” between 
the user mission’s MOC and a service providing station of the Integrated Network. 


V. End State Architecture 

Given the conclusions for each of the three functions as stated in Section IV, the overall architecture for the 
NASA integrated space communications network has emerged. Figure 9 illustrates the end state architecture. The 
three network elements will have common service execution and network control at the various ground station sites 
(GSSs). The three network operations nodes (NONs) will have common network control capabilities as well to 
conduct the global, remote network monitor and control operations using the folio w-the- sun approach. A service 
portal will provide human-machine interface to user missions for their service management and network control 
activities. The portal will eventually become an integral part of the integrated network operations center (INOC) that 
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facilitates the centralized service management functions as the various network elements migrate out of the common 
service management paradigm. 


Integrated Network 
The End State Architecture - 


GSS: Ground Station Site 
NON: Network Operations Node 
INOC: Integrated Network Operations Center 
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Figure 9. Integrated Network - The End State Architecture 
VI. Conclusions 

The integrated space communications network defined so far has provided a foundation for programmatic 
planning at NASA. An incremental, phased development approach to realizing the integrated network is being 
formulated. Moreover, NASA will proceed with the implementation of certain pieces of the integrated network as 
the initial effort toward the end state architecture. 
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Appendix A 
Acronym List 


ACP 

Asset Contention Period 

AoA 

Analysis of Alternatives 

CCSDS 

Consultative Committee for Space Data Systems 

COO 

Continuity of Operations Option 

COOP 

Continuity of Operations 

CSTS 

Cross Support Transfer Service 

DSE 

Deep Space Element 

DSN 

Deep Space Network 

EBRE 

Earth Based Relay Element 

El 

Enterprise Infrastructure 

FOM 

Figure of Merit 

GEO 

Geostationary Earth Orbit 

GSS 

Ground Station Site 

GT 

Ground Terminal 

HEO 

High Earth Orbit 

INC 

Integrated Network Control 

INOC 

Integrated Network Operations Center 

ISM 

Integrated Service Management 

ISE 

Integrated Service Execution 

LEO 

Low Earth Orbit 

MOC 

Mission Operations Center 

NCS 

Network Control Software 

NCO 

Network Control Operations 

NEE 

Near Earth Element 

NEN 

Near Earth Network 

NON 

Network Operations Node 

SCaN 

Space Communication and Navigation 

SLE 

Space Link Extension 

SN 

Space Network 

TDRSS 

Tracking and Data Relay Satellite System 

TT&C 

Telemetry, Tracking and Command 
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